home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1100 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.0 KB  |  72 lines
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: johnw@jove.acs.unt.edu (John R. Williams)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: C++ syntactic trap
  5. Date: 15 Apr 1996 22:32:24 GMT
  6. Organization: University of North Texas
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4kuigg$nbr@hermes.acs.unt.edu>
  9. References: <4k3q4p$lkd@syn.cs.cornell.edu> <4kcrhk$aj1@hermes.acs.unt.edu> <KANZE.96Apr10111924@gabi.gabi-soft.fr>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. X-Nntp-Posting-Host: jove.acs.unt.edu
  12. X-Newsreader: TIN [version 1.2 PL2]
  13. Content-Length: 2058
  14. X-Lines: 48
  15. Originator: clamage@taumet
  16.  
  17. J. Kanze (kanze@gabi-soft.fr) wrote:
  18. > In article <4kcrhk$aj1@hermes.acs.unt.edu> johnw@jove.acs.unt.edu (John
  19. > R. Williams) writes:
  20.  
  21. >     [Concerning a warning for `new char( 10 )'...]
  22. > |> I agree that it is uusual to allocate a single object of a built-in type 
  23. > |> this way, but how do you propose to write this in such a way that such a 
  24. > |> warning would not be generated? All I can think of is to warn when *any* 
  25. > |> conversion occurs (this one looks pretty explicit to me), forcing you to 
  26. > |> write something like this:
  27.  
  28. > |>   char *foo = new char(static_cast<char>(10));
  29.  
  30. > |> (Actually this rule doesn't seem too bad if applied only to built-in 
  31. > |> types...)
  32.  
  33. > Let's see:
  34.  
  35. >     int*        pi = new int( static_cast< int >( 10 ) ) ;
  36.  
  37. > Do you want the compiler to warn if you omit the static_cast (of int to
  38. > int)? 
  39.  
  40. What I meant (but perhaps did not make clear) is that the warning would 
  41. only be in the case of *conversions* (and possibly promotions). In this 
  42. case my rule would allow more comfortable syntax without a warning.
  43.  
  44. > I do not think that I have a single instance of allocation of an array
  45. > in any of my code.  Why should you make the most frequent case the most
  46. > difficult.  (And allocating a single int is not that infrequent.  You
  47. > might look at the implementation of counted_ptr in Barton and Nackman,
  48. > for example.  It is certainly more frequent than allocating an array of
  49. > int's, at least in well written C++ code.)
  50.  
  51. I admit that since I get a copy of HP's STL I have almost entirely 
  52. stopped using array new, but OTOH I can't remeber a single time I've 
  53. allocated just one object of a built-in type. This suggests to me that
  54. the issue is one of of style and context, not ability to program.
  55.  
  56. At any rate, I don't like my idea either--I was just throwing it out to 
  57. see what people would think.
  58.  
  59. --
  60. class JohnWilliams: public Student, public Programmer {
  61. public:
  62.   char const *operator&() const { return "johnw@jove.acs.unt.edu"; }
  63.   char const *homepage () const { return "http://www.unt.edu/~johnw"; }
  64. };
  65.  
  66.  
  67. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  68. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  69. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  70. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  71. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  72.